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DAIS  DOCUMENTATION 


1.  INTRODUCTION 

The  Digital  Avionics  Information  System  (DAIS)  has  developed  stan¬ 
dardized  core  elements,  support  hardware  and  support  software.  By  using 
these  elements  as  a  standardized  system  the  life  cycle  cost  of  conventional 
avionics  systems  can  be  reduced.  However,  a  most  important  aspect  of  the 
DAIS  program  is  documentation,  because  the  DAIS  specifications,  manuals,  plans 
drawings  and  test  reports  permit  the  dissemination  to  industry  and  to  other 
government  agencies  the  knowledge  and  experience  gained  from  the  program. 

Using  MIL-STD  U83,  Configuration  Management  Practices  for  Systems,  Equipment, 
Munitions  and  Computer  Programs  and  U90,  Specification  Practices  as  guidelines 
the  objective  of  this  effort  was  to  provide  configuration  control,  technical 
editing  and  generation  of  DAIS  documentation.  The  AFWAL/AAAS  functional 
organization  established  to  carry  out  these  tasks  is  outlined  in  Figure  1. 

Implementation  of  a  configuration  management  program  as  an  Inte¬ 
gral  part  in  the  development  of  a  system/program  provides  the  means  of 
complete  and  concise  management  controls .  Each  item  of  hardware ,  software 
and  supporting  data,  which  initially  generates  the  concepts  and  criteria  in 
overall  system  development  and  deployment,  receives  full  management  visibility. 
Normally,  there  are  three  basic  elements  of  configuration  management  to 
consider  when  planning  the  evolution  of  a  system/program:  (l)  configuration 
identification,  (2)  configuration  control,  and  (3)  configuration  status 
accounting.  These  three  elements,  applied  in  a  uniform  interrelated  pattern, 
assure  maximum  control  of  all  items  within  a  system  through  the  conceptual, 
design  and  development,  test,  production  phases  and  the  subsequent  deploy- 


AFWAL/AAAS  FUNCTIONAL  ORGANIZATION 


ment  of  the  system.  At  all  times,  a  control  or  management  tool  is 
available  to  assure  the  high  level  of  confidence  which  is  required  and 
expected.  Figure  2  shows  the  flow  and  activity  required  to  bring  the 
Digital  Avionics  Information  System  (DAIS)  Program  into  phase  with  the 
standard  program  principles  of  configuration  management  and  individual 
item(s)  controls. 

1.1  DAIS  Configuration  Management  Implementation  Plan 

To  obtain  control  of  the  DAIS  configuration  Items  of  hardware 
and  software,  two  major  phases  were  necessary.  The  first  phase  involved 
documentation  and  the  second  related  to  the  hardware  and  software  and 
their  relationship  to  the  documentation. 

1.1.1  Phase  I  -  Documentation  Control 

This  phase  required  a  continuing  effort  in  gathering,  reviewing, 
cataloging,  and  filing  all  DAIS  specifications,  interface  control  documents, 
user's  manuals,  engineering  drawings,  and  the  test  plans  and  procedures. 

An  important  feature  of  this  phase  was  the  review  which  resulted  in  the 
development  of  document  status  with  respect  to  past,  present,  and/or 
scheduled  approval. 

1.1.2  Phase  II  -  Product  Control 

All  existing  items  of  hardware  and  software  being  used  for  the 
development  of  the  DAIS  program  should  have  undergone  an  audit  (functional 

and/or  physical)  to  determine  if:  (l)  the  hardware  met  the  criteria  esta¬ 
blished  in  the  specifications  and  was  compatible  with  the  associated 

engineering  drawing  package;  (2)  all  software  had  been  developed  as  required 
by  the  specifications  and  wan  compatible  with  the  associated  listing  docu¬ 
ments;  and  (3)  both  hardware /software  and  data  were  in  direct  relationship 


PHASE  l-DATA  CONTROL 


to  the  acceptance  test  plans  and  subsequent  test  reports . 

Time  and  money  constraints  prevented  audits  on  all  of  the  items. 
Hovever,  of  the  Items  audited  any  and  all  discrepancies  were  logged,  and 
directives  for  corrective  actions  were  Issued  to  correct  the  inconsist- 
cies. 
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SCOPE 


«s 


2. 

The  documentation  effort  encompassed  the  following  functions: 

(l)  maintaining  the  DAIS  library;  (2)  generating  certain  specifications, 
plans,  drawings  and  or  test  ret  rts;  (3)  performing  configuration  audits 
per  MIL-STD  1521;  (U)  Assuring  the  DAIS  documents  conformed  to  MIL-STD  U83 
and  1»90;  (5)  technical  editing;  (6)  maintaining  configuration  control 
over  all  DAIS  documents.  Table  I  shows  the  Work  Breakdown  Structure  (WBS) 
for  work  performed  on  this  contract.  This  report  will  address  the  tasks 
in  the  sequential  order  of  the  WBS  by  stating  the  task,  how  it  was  approached 
and  what  the  results  of  each  effort  were. 

This  report  will  cover  the  activities  of  the  contractor  support 
of  the  Configuration  Management  Office  (CMO)  for  the  period  of  1  Aug  1979 
to  1  June  1981. 
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3. 


BACKGROUND 


3.1  Past  and  Present  Status 

At  the  start  of  the  contract  the  DAIS  documentation  system  had 
156  specifications ,  23  drawings ,  29  manuals ,  54  plans  and  19  test  reports 
for  a  total  of  281  and  of  these,  113  specifications,  12  drawings,  23  manuals , 

26  plans  and  8  test  reports  bad  been  released.  A  growth  of  about  40iJ  in 
the  total  number  of  documents  was  anticipated  by  30  Sep  80.  This  growth 
and  more  did  take  place  due  to  the  conversion  of  the  baseline  documents  to  the 
new  MIL-STDs  of  155 3B  Aircraft  Internal  Time  Division  Coamand/Response 
Multiplex  Data  Bus,  1589A  Jovial  J-T3,  and  1750A  Sixteen-Bit  Computer 
Instruction  Set  Architecture .  The  total  number  of  documents  at  30  April  1981 
was  410,  comprised  of  216  specifications,  24  drawings,  49  manuals,  8l  plana, 
and  40  test  reports  for  a  growth  of  l46j5. 

3.2  DAIS  Document  Description  Manual 

A  list  of  existing  and  planned  DAIS  documents  is  given  in  MA100100, 

DAIS  Document  Description  Manual.  This  document  includes  a  scope  state¬ 
ment  for  each  document,  an  explanation  of  the  DAIS  document  numbering 
system  (Figure  3),  and  a  breakdown  of  the  different  classes  of  documents. 

SYSTRAN  undated  the  document  to  a  "C"  revision  in  May  of  1980  with  an  addi¬ 
tion  of  over  80  new  docunents,  to  a  "D"  revision  in  April  of  1981,  and  to 
an  "E"  revision  in  May  of  1981.  In  excess  of  240  MA100100  docvsnents  have  been 
distributed  to  government  agencies  and  civilian  contractors  who  have  an  Interest 
in  the  DAIS  concept. 
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TECHNICAL  TASKS 


u. 

The  following  technical  tasks  were  called  out  in  the  contract- 
ural  Instrument.  The  paragraphs  subsequent  to  the  statement  of  the  techni¬ 
cal  task  will  describe  how  the  task  was  approached,  carried  out  and  the 
results  of  the  effort. 

4.1  Library  Maintenance  (Task  1) 

The  contractor  shall  maintain  the  DAIS  library  located  in  Bldg  620, 
WPAFB.  The  library  will  hare  approximately  180  documents  at  contract  start 
and  estimated  total  of  250  documents  at  contract  end.  However,  due  to  the 
decision  to  convert  the  baseline  documents  to  the  nev  MIL-STDs,  the  total 
number  of  documents  at  contract  end  was  410. 

4.1.1  Printing  of  DAIS  Documents 

The  contractor  shall  arrange  to  have  1,500,000  pages  of  approved 
and  draft  DAIS  documents  printed  by  the  Air  Force  printing  office. 

4. 1.1.1  Printing  Request 

This  task  vas  accomplished  by  the  initiation  of  DD  Form  843, 

Request  for  Printing  by  the  librarian.  (Figure  4).  This  form  vas  then 
approved  by  the  CM0  and  Branch  Chief,  routed  through  Air  Force  channels  for 
approval  before  going  to  the  printing  office.  Normal  turn-around  time  for 
the  printing  vas  ten  vorking  days. 

The  documents  vere  tracked  by  means  of  the  DAIS  Document  Distri¬ 
bution  Status  Report  to  insure  timely  return  from  the  printing  office.  When 
the  document  vas  returned  from  printing,  the  Printing  Request  form  vas 
annotated  with  the  return  date  and  filed  in  the  permanent  section  of  the 
Status  book.  If  a  subsequent  request  vas  initiated,  the  original  quantity 
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and  order  date  was  entered  on  the  file  copy  of  the  second  request*  Through 
this  mechanism  it  was  possible  to  maintain  a  complete  history  of  when  and 
how  many  copies  of  a  particular  document  were  printed. 

Documents  that  required  fast  turn-around,  had  a  small  number  of 
pages ,  or  less  than  the  standard  number  of  copies ,  were  reproduced  at  the 
SYSTRAN  main  office.  This  provided  timely  service  especially  for  review 
team  activities  which  were  operated  on  a  short  time  span.  During  the 
contract,  139*321  copies  were  reproduced  at  the  contractor  facility. 

U. 1.1.2  Printed  Documents 

The  stated  goal  to  have  1,500,000  pages  of  DAIS  documents  printed 
by  the  Air  Force  printing  office  was  not  attained.  This  figure  was  based 
on  historical  data  which  subsequently  was  proven  inaccurate.  Also,  the 
standard  distribution  list  for  DAIS  documents  was  reduced  from  twenty  three 
to  twelve  copies.  6133  copies  of  documents  were  printed  by  the  Air  Force 

printing  office  totaling  608,590  pages. 

4.1.2  Distribution  of  DAIS  Documents 

The  contractor  shall  distribute  approximately  40  copies  of  100 
DAIS  documents  (4000  copies)  to  contractors  and  other  government  agencies. 
This  distribution  shall  be  via  government  postage- free  mail.  Records  of 
who  receives  the  documents  are  to  be  maintained  by  the  contractor. 

4. 1.2,1  Master  Distribution  List 

A  master  standard  distribution  list  that  was  approved  by  the 
chief  of  the  DAIS  Program  Branch  was  maintained  in  the  Document  Distri¬ 
bution  Register.  (Table  II).  This  list  was  reviewed  and  revised  periodi¬ 
cally  to  reflect  the  current  desires  of  the  users.  As  stated  above,  this 
list  was  reduced  from  twenty  three  from  September  1979  to  twelve  in 
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Table  II 
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_ STANDARD  DISTRIBUTION 

AFATL/DLMM,  CAPT.  R.  BUTLER, 

EGUN  AFB,  FLORIDA  32842 

ADTC/DLJA,  ATTN:  JOHN  GAVIN, 

EQLIN  AFB,  FLORIDA  32842 

AFFTC/TEESD,  MR.  JIM  UNDERWOOD, 

STOP  239,  EDWARDS  AFB,  CALIFORNIA  93823 

AFWAL/FK3X,  CAPT.  K.  RACE 
AFWAL/AAD,  W.  EDWARDS 
ASD/ENAL  E.  GANGL 

ASD/AER,  CAPT.  WHITMAN 
ASD/XER,  T.  P1ENBOWSKI 
AFWAL/AAAS-3,  CAPT.  DROBOT 
AFWAL/AAAS-1,  D.  SNYDER 
SYSTRAN  CORP. 

INTER  METRICS,  A.  WOLFE 


* 


TRW/SITC,  R.  MASON 


December  1980. 

Upon  return  of  the  copies  from  the  printer,  the  standard  distri¬ 
bution  was  made.  The  information  was  recorded  on  the  Document  Register  which 
included  date,  number  of  copies,  organization,  name  and  mailing  address. 
(Figure  5).  Through  this  method  it  was  possible  to  know  who  had  what  docu¬ 
ments  and  what  the  remaining  inventory  count  was  at  any  given  time. 

4. 1.2. 2  Distribution  of  Revisions 

Upon  receipt  of  the  copies  from  the  printer,  the  distribution 
record  of  the  affected  document  was  used  as  a  mailing  list.  Proper  entries 
were  made  next  to  the  individual  organization  to  insure  that  all  holders 
of  the  baseline  document  received  all  updates  to  that  document.  Normally 
extra  copies  of  the  revisions  were  printed  to  insure  complete  update  in 
the  event  the  holders  of  the  basic  document  lost  their  revision  prior  to 
incorporation  into  their  document. 

4 . 1 . 2 . 3  Special  Requests  for  Distribution 

Request  for  particular  documents  were  honored  and  the  documents 
were  distributed  via  government  postage-free  mail  under  cover  of  Transmittal 
of  DAIS  Document  form  letter.  If  the  request  was  not  definitive  as  to  a 
particular  document,  then  MA100100,  DAIS  Document  Description  Manual,  was  sent 
to  the  requestor.  Not  only  does  this  manual  contain  a  short  descriptive 
summary  of  what  is  in  each  document  but  it  also  contained  the  DAIS  Spec¬ 
ification  Tree  and  instructions  on  how  to  order  any  of  the  DAIS  Documents. 

4. 1.2. 4  Documents  Distributed 

This  task  set  a  goal  of  40  copies  of  100  DAIS  Documents 
(4000  copies).  During  the  life  of  the  contract,  a  total  of  5114  copies  of 
over  295  documents  were  distributed,  and  at  contract  end  there  were  3649 
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copies  of  DAIS  Documents  on  hand  in  the  library. 

^.1.3  Inventory  Maintenance 

The  contractor  shall  maintain  extra  copies  of  documents  in  an 
easily  accessible  manner  in  office  space  to  be  provided  in  Building  620 
at  WPAFB.  Additional  copies  shall  be  ordered  an  required  to  maintain  an 
inventory.  File  cabinets  and  bookcases  for  storage  will  be  provided  by 
the  government. 

U. 1.3.1  Quantity  of  Copies 

An  adequate  quantity  of  extra  copies  was  maintained  in  an  easily 
accessible  manner  in  the  library.  The  distribution  register  was  the  prime 
source  of  the  number  of  copies  that  were  on  hand. 

When  the  number  of  copies  dropped  to  a  one  month  supply  based 
on  previous  consumption,  a  printing  re-order  was  initiated.  The  responsi¬ 
ble  engineer  was  contacted  in  order  to  determine  If  there  were  any  revisions 
to  the  document  being  planned.  If  there  was  a  revision  planned,  the 
minimum  number  of  copies  were  ordered  and  if  there  were  no  changes  planned, 
then  a  six  month  supply  was  ordered. 

During  the  period  of  the  contract  there  were  915  copies  reordered 
involving  62  documents. 

U.l.U  Master  File  Maintenance 

The  contractor  shall  maintain  a  master  file  of  documents  both 
released  and  under  review.  It  was  estimated  that  200-300  documents  would 
be  maintained.  However,  due  to  the  MIL-STD  conversion  effort,  the  total 
number  of  documents  grew  to  UlO  by  30  April  1981. 

U.l.U.l  Master  Document  File 

One  of  the  most  important  aspects  of  configuration  control  is 


* 

f 

£ 

* 


y 


traceability,  the  single  thread  that  allows  tracing  the  genesis  of  a  Cl 
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its  documentation  baselines  and  all  changes  that  have  been  made.  To  accom¬ 
plish  this,  the  DAIS  library  established  a  folder  for  each  document  that  the 
Program  Branch  controlled. 


Each  folder  provided  a  complete  chronological  history  of  the  docu¬ 
ment  which  was  recorded  on  DAIS  Form  78-03,  Document  for  CCB  Review  (Figure  6). 
In  addition,  the  folder  contained  the  originating  letter,  with  scope  statement, 
that  requested  the  document  be  incorporated  into  the  DAIS  system  (Figure  7); 
the  review  team  letter  recommending  approval  of  the  document;  (Figure  8) 
and  any  other  correspondence  regarding  the  history  of  changes  made  to  the 
document . 

U.l.U.2  Library  Files 

A  filing  system  was  developed  using  the  designated  document  type 
identifier  for  specification,  drawings,  manuals  and  program  documents. 

Document  type  designations  were  filed  alphabetically  to  aid  in  expediting 
retrieval  actions.  A  master  list  of  the  documents  was  maintained  in 
PAOOO^OO,  DAIS  Document  Status  Plan.  (Figure  9).  This  document  was  a 
computer  printout  that  listed  all  specifications,  drawings,  manuals,  plans 
and  test  reports  in  relation  to  their  draft  due  dates/release  dates. 
Documentation  Control  Board  review  status  and  responsible  engineer  and/or 
contractor . 

U.1.U.3  Library  Functions 

Associated  functions  of  the  library  filing  system  included: 
a)  Receipt  and  recording  of  all  Configuration  Control  Board  Directives 
(CCBD)  (FigurelO  )  that  related  to  the  data  in  the  file  (i.e.  revisions  or 
new  document  approval,  recoamended  or  directed  actions  of  agencies  or  con¬ 
tractors  involved  with  specific  documentation). 
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DOCUMENT  FOR  CCS  REVIEW 


DOCUMENT  NO.  _ 

TITLE  _ 

RESPONSIBLE  ENQINEER 
PROJECTED  DUE  DATE  . 

DATE  SUBMITTED  TO  CMO  _ 

RECOMMENDED  REVIEW  TEAM: 

TEAM  LEADER  _ 

TEAM  MEMBERS  _ 

GROUP  LEADER'S  INITIALS  _ 

DATE  TO  CCB  _  DATE  REVIEW  TEAM  ACTIVATED 

INITIAL  REVIEW  S _  CCB  APPROVAL  S — 

A _  A  — 

PRELIMINARY  REVIEW  S _  DATE  TO  PRINTING 

A _  DATE  RETURNED 

PINAL  REVIEW  S _  DATE  DISTRIBUTED 


Figure  6.  DOCUMENT  FOR  CCB  REVIEW 
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MEMO  FOR  THE  RECORO 


SUBJECT:  Request  for  a  Document  Number 


TO:  CMO  (R.  Jones) 

1.  It  Is  requested  that  (document  title)  be  placed  under  DCB 
control  and  a  number  assigned.  A  tentative  number  Is 
(Specify  a  number  only  If  received  from  CMO)  The  responsible 

engineer  for  this  document  Is  _ _ _ 

and  a  draft  copy  for  review  w^l  be  available  during  (Month  and~~Year 

2.  The  scope  statement  Is  as  follows: 


_  Cy  to:  F.  Forster 

XXXXX  (Group  Leader) 

(Responsible  Engineer) 


Figure  7.  ORIGINATING  LETTER  WITH  SCOPE  STATEMENT 
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MEMO  FOR  THE  RECORD 

SUBJECT:  (Document  Title  and  Number) 

TO:  DCB  (T.  Brim) 

1.  The  OAIS  DCB  review  team  has  completed  Its  review  of  the 
subject  document.  The  following  changes  were  Incorporated: 


or 

This  document  Is  being  rejected  for  the  following  reasons: 

a.  (List  major  changes  or  reasons  for  rejection.) 

b. 

c. 

2.  The  review  team  recommends: 

a.  That  the  subject  document  be  approved  or  rejected  and 
rewritten,  etc. 

b.  That  the  review  team  be  disbanded. 


XXXXXX  XXXXXXX 

Team  Leader 


XXXXXX 


XXXXXXX 


Cy  to:  M.  O'Connor 
D.  Snyder 
Capt  O'Brien 
R.  Jones 
R.  Mason 
M.  Thu lien 


R.  Price 
Capt  DeSanto 
F.  Forster 
R.  Bailey 
N.  Kopchlck 


Figure  8.  REVIEW  TEAM  LETTER 
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b)  Recorded  and  incorporated  all  approved  specification  change  notice 
packages  received.  Replaced  data  with  superseding  data  when  approved  by  the 
CCB. 

c)  A  master  copy  of  all  software  components  was  made,  identified  and 
secured.  When  approved  changes  were  authorized  to  a  software  component, 
the  copy  was  used  for  implementation  of  the  changes.  Subsequent  to  the 
necessary  functional  tests,  the  new  version  was  entered  into  the  library, 
reidentified,  and  a  master  copy  was  again  made  for  the  secure  file. 

d)  A  master  file  was  created  and  maintained  for  all  ECP/SCNs 
(Figures  11  &  12)  received  from  agencies  or  contractors.  Numbers  for 
ECP/SCNs  were  consecutively  assigned,  beginning  with  number  one  and  on,  for 
each  document.  The  ECP/SCNs  were  maintained  in  separate  folders  from  the 

time  they  were  received,  until  final  action  of  the  CCB  (approval  or  disapproval). 
Also  Included  in  these  folders  were  all  follow-up  and  implementation  directions , 
such  as  delivery  dates  of  final  SCNs ,  engineering  modification  kits  or 
other  required  information. 

e)  A  deletion/historical  file  was  maintained  for  all  documents  deleted 
from  the  system  and  other  documents  that  had  an  association  with  the  develop¬ 
ment  of  DAIS.  A  master  listing  of  these  documents  was  contained  in  PA000500, 
DAIS  Deletion/Historical  Document  List  (Figure  13).  This  printout  contained 
the  deleted  document  number,  title  and  date.  The  historical  documents  were 
assigned  sequential  code  by  calendar  year  of  publication. 

f)  A  reference  file  of  DOD  Directives,  AF  Regulations,  AFSC  Regulations 
and  Pamphlets  and  Military  Standards  for  use  by  branch  engineering  and 
supporting  contractors  was  maintained.  When  personal  copies  of  MIL  Standards 


were  required t  they  were  ordered  from  the  Engineering  Data  Support  Center 
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10.  OTHER  SYSTKMK  AFFECTED 


17.  OTHER  CONTRACTS/ ACTIVITIES  AFFECTED 


IS.  CONFIOURATION  ITEMS  AFFECTED 


Figure  11.  ENGINEERING  CHANGE  PROPOSAL 
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Figure  11.  ENGINEERING  CHANGE  PROPOSAL  (con't) 


I 


SPECIFICATION  CHANGE  NOTICE 

(S40  M/L- STD-490  For  Instruction* 


I.  OriQirafor  Noma  and  Addr«<« 


LIMA 


7.  System  Designation 


8.  Rilotid  ECP  Mo. 


.  Configuration  I  tom  Nomenclature 


9.  Contract  Mo. 


12.  Effectivity 


3.  Code  Ident. 

4.  Spec.  No. 

5.  Code  Ident. 

6.  SCN  No. 

10.  Contracted  Activity 


This  notice  informs  recipients  that  the  specification  identified  by  the  number  (and  revision  tetter) 
shown  in  block  4  has  been  changed.  The  pages  changed  by  this  SCN  being  those  furnished 
herewith  and  carrying  the  same  dote  oe  this  SCN.  The  pages  of  the  page  numbers  and  dates  listed 
bdow  in  the  summary  of  changed  pages,  combined  with  non- listed  pages  of  the  original  issue  of  the 
revision  shown  in  dock  4,  constitute  the  current  version  of  this  specification. 


13  SCN  No.  14 


Pages  Changed  (Indicate  Deletions) 


to  Technical 


*  9  in dicofee  supersedes  eorfler  page.  A  Mfcofee  added  page. 

Figure  12.  SPECIFICATION  CHANGE  NOTICE 
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maintained  by  AFALC/PTD. 

g)  A  master  file  was  maintained  for  Configuration  Control  Board 
Meeting  Minutes ,  Problem  Report  Board  Meeting  Minutes ,  Test  Control  Board 
Meeting  Minutes ,  Product  Control  Board  Meeting  Minutes ,  Open  Problem  Reports 
and  Closed  Problem  Reports.  (Figure  Ik). 

h)  A  master  of  DA100100,  DAIS  Document  Tree  (Figure  15)  was  maintained. 
This  is  a  drawing  that  contained  all  specifications,  manuals,  and  plans  in 
relation  to  seven  functions  in  the  system,  l)  Core  Elements,  2)  Non-Real- 
Time  Support  Software,  3)  Real-Time  Support  Software,  k)  Test  Software, 

5)  Support  Hardware,  6)  Interfaces  and  7)  Mi ss ion* Dependent .  In  addition 
the  diagram  reflected  whether  the  document  was  released  or  not.  In  order 
to  facilitate  the  updates  to  this  diagram  it  was  put  on  the  Applicon,  which 
is  a  computer-generated  diagram.  This  reduced  the  time  to  update  the  diagram 

from  weeks  to  days.  The  diagram  was  updated  four  times  and  grew  from  one 
to  two  sheets  to  accommodate  the  increase  in  the  number  and  type  of  docu¬ 
ments  included. 

4.2  Preparation  of  DAIS  C/D  Subsystem  Application  S/W  (Task  2) 

The  contractor  shall  develop  the  specifications,  SA501360-1  and 
SA501360-2,  DAIS  C/D  Subsystem  Application  S/W,  MPDG-1,  MPDG-2,  type  C-5  / 
specifications.  Actual  software  listings  will  be  provided.  There  are  approx¬ 
imately  65,000  lines  of  assembly  level  code  (data  included)  including  comment 
lines  for  the  program.  The  number  of  pages  for  each  specification  is  esti¬ 
mated  at  400. 

4.2.1  Specification  Preparation 

The  following  paragraphs  describe,  in  summary  form,  the  major 
steps  of  the  process  taken  to  develop  a  software  specification,  and 
examples  are  shown  of  some  of  the  results  of  the  steps  in  this  process. 
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DAIS  PROBLEM  REPORT  FORM 

CONTROL  USS  ONLY 

MO. 

OHMUNATOM*  _  MONO  MO, 

OROAMIZATlOMf  OATO, 

OAT* 

INITIAL*  -  - 

(a)  PROBLEM  CLASSIFICATION:  SYS 

M/w  e/n  Maras 

ft/W 

(3)  1 

VBNSIOM:  MHOMITV*  UROBMT  OOIITIMM 

mobijm  TmjyMicavnoib 

ARRAS  MVACTRD:  DOCUMSNTS _  S/W _  M/W 

MTBVACI _  TUTS _ 

RLII/TANI _ 

mtrractivr  mom _  batch  mom _ 

*'  MV  ACT  STATRMSNT: _ 


<•*  OATS  NUOU _  MOMW  R1FORT  PRIORITY:  UROCNT _  BOUTINS  _ 

PROROSSD  ACnONi 


RSSFONSSLS  BMOMUM _  OATS  AMKMIO_ 

OATS  TO  Bl  COMRLSTRD _  OATS  COMPLETED 

proposed  soumoNt  accepted _  rejected _ 

doumo _  ccs _ 

HWUM  COORDMATOS _ 

ACCEPTED  SOUmON/VSMFICATION: 


VWfBO  BY:  DATE: 

PSSAS  ftWAi.  OATS: _ 

ASIA  UPDATED:  SYS _  S/W _  M/W _  VERSION 

C/O _  MSTSS _  OOCUMSNT _ 


tan  No.  DAM  TS-04 
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b.2.2  Phase  I,  Preparation 

a.  Obtained  and  reviewed  all  available  manuals.  Government  and 
Non-Government  documents  (e.g.,  language  manuals  and  develop¬ 
ment  specifications)  used  in  the  preparation  of  the  software 
from  the  AAAS  engineer.  This  supplied  the  writer  with  technical 
background  which  afforded  him  a  better  understanding  of  the 
overall  mechanics  of  the  program. 

b.  Obtained  a  program  listing  and  acquired  a  thorough  understand¬ 
ing  of  the  code  in  which  the  program  was  written.  Consulted  the 
AAAS  engineer  for  information  as  to  the  most  appropriate  refer¬ 
ence  material. 

U.2.3  Phase  II,  Initial  Review  and  Schedule  Development 

a.  Reviewed  the  listings  of  the  software  and  compiled  an  overall 
detailed  description  of  the  function  of  the  computer  program 
as  a  whole. 

b.  Prepared  a  block  diagram  of  the  overall  software /hardware  configu¬ 
rations  . 

c.  Delineated  conventions  of  the  various  register  usages  in  regards 
to  the  individual  Computer  Program  Components  (CPC). 

d.  Listed  a  breakdown  of  separate  stages  of  the  software,  such  as 
any  main  modules  and  files ,  internal  testing  routines  and  the 
supporting  subroutines  of  the  package. 

e.  Prepared  a  rough  draft  outline,  using  the  outline  in  Appendix -VI 
of  MIL-STD-U83  and  the  information  gathered  during  the  initial 
preparation.  Included  the  topics  to  be  covered  within  each 
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paragraph.  Reviewed  this  draft  outline  with  the  responsible 
engineer  who  provided  the  do  c  lime  nt  at  ion  team  with  essential 
comments  *  suggestions  and  guidelines.  Figure  16  shows  a  typical 
outline  of  a  software  product  specification, 

f.  Established  the  time  required  for  each  of  the  following  tasks: 
Development  of  text  and  flowcharts 
Typing  of  text 
Drafting  of  flowcharts 
Corrections 
Review  of  final  draft 

A  schedule  was  then  developed  considering  the  number  of  lines  and 
number  of  CPCs  to  be  documented.  This  schedule  not  only  allowed 
for  the  calculation  of  a  completion  date,  but  also  provided  the 
documentation  team  with  a  basis  against  which  to  measure  its  pro¬ 


gress  . 

g.  Prepared  a  format  for  constructing  figures  and  tables  which  pro¬ 


vided  consistency  across  all  CPCs. 

h.  Drafted  an  outline  of  the  proposed  method  of  formatting  the  final 
document  and  submitted  this  for  review  by  the  AAAS  engineer. 


U.2.U 


Phase  III ,  Detailed  Development 


a.  Prepared  a  detailed  description  of  the  functions  of  each  of  the 
CPCs,  identifying  these  by  titles  and  programmer- as signed  mnemonics, 

b.  Prepared  a  detailed  flowchart  for  each  individual  "PC. 

c.  Listed,  with  a  detailed  description  of  each,  all  interfaces  to 
each  CPC  and  the  relationships  to  one  another. 
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SOFTWARE  PRODUCT  SPECIFICATIONS 


d.  Compiled  a  list  of  all  subroutines  called  by  each  CFr  and  gave 


a  brief  description  of  each. 

e.  Listed  sill  global  data  relevant  to  each  CPC.  Prepared  a  brief 
description  of  each  and  its  word  lengths . 

f.  Listed  the  limitations,  if  any,  that  each  CPC  may  have,  such  as 
timing  requirements,  error  checks  programmed  into  the  routine  or 
any  other  restrictions  that  applied  to  the  individual  CPCs.  The 
AAAS  engineer  was  consulted  when  the  writer  felt  there  was  insuf¬ 
ficient  data  concerning  the  limitations  listed  in  the  initial 
reference  manuals . 

g.  A  table  of  contents  applicable  to  the  individual  CPC’s  was  made 
with  a  brief  description  of  each. 

4.2.5  Document  Review 

When  the  draft  of  the  document  was  completed,  it  was  submitted 
for  an  initial  review  by  the  AAAS  responsible  engineer.  The  author  of  the 
document  went  through  the  document  with  the  responsible  engineer  to  make 
notes  on  desired  changes.  After  this  review,  the  document  was  put  in  final 
form  and  delivered  to  the  Air  Force.  When  the  document  was  put  into  the 
review  cycle,  the  author  served  on  the  review  team  and  kept  a  master  copy 
of  all  changes  made  during  the  review  cycle.  The  document  was  then  updated 
for  the  final  approval  sign-off.  SA  501  360-1,  MPDG-1,  in  final  form 
contained  39L  pages  and  SA  501-360-2,  MPDG-2  contained  336  pages. 

4.3  Drafting  Support  (Task  3) 

The  contractor  shall  provide  drafting  support  for  figures,  tables, 
and  layouts  for  documents  under  review  as  well  as  drawings ,  layouts  and 


v 


illustrative  material  for  use  by  the  Configuration  Management  Office  (CMO). 
It  is  estimated  that  an  average  of  10  hours  per  week  shall  be  required. 

The  average  number  of  drawings  per  week  is  estimated  at  5  small  drawings 
or  1  large  drawing.  Development  of  100  view-graphs  or  presentation  aids 
shall  be  required. 

U.3.1  Support  Provided 

During  the  period  of  the  contract  the  following  drafting  support 
was  provided: 


Drawings 

78 

View-graphs 

91 

Prints 

57 

Tables /Figures 

21k 

Editing  (Task  U) 

The  contractor  shall  perform  the  editing  function  as  defined 

below.  Documents  may  be  in  draft  form,  released,  under  revision  or  sub¬ 
mitted  by  contractors.  Change  notices  to  released  documents  may  also  be 

£ 

edited.  I 

^.^.1  Technical  Editing/Rewrite  ? 

a 

The  contractor  shall  technically  edit  and  rewrite  1000  pages  ; 

of  hardware  and  software  specifications,  manuals  and  plans.  Normally  an  * 

engineer/tech  writer  from  the  documentation  contractor  will  work  closely 
with  the  DAIS  responsible  engineer  in  this  task. 


36 


>  4  ?■*.**. 


4. 4.1.1  Editing/Rcwritim 


& 

When  editing  or  rewriting  a  document,  it  was  first  determined 
exactly  what  information  the  document  contained,  then  it  was  studied 
carefully  and,  thoroughly  understood.  The  information  was  then  organized 
to  follow  the  outline  presented  in  the  appropriate  appendix  of  MIL-STD-490 . 
The  text  sometimes  was  more  clearly  presented  and,  thus,  more  easily  under¬ 
stood  when  some  information  was  reorganized  into  tables  and  figures.  A 
table  is  an  arrangement  of  data  in  lines  and  columns ,  whereas  a  figure  is 
a  picture  or  graphic  representation  of  a  concept.  References  in  the  text 
were  sufficiently  detailed  to  make  the  purpose  of  the  table  or  figure  clear. 
The  documentation  staff  worked  closely  with  the  engineer  to  assure  that  the 
information  was  represented  correctly  and  was  included  within  the  appropriate 
sections . 

As  the  document  was  reorganized  it  became  apparent  whether 
additional  information  was  needed  to  satisfy  all  the  requirements  of 
MIL-STD-483  and  -490.  Once  the  source  of  the  needed  information  was  identi¬ 
fied,  the  documentation  team  and  the  responsible  engineer  proceeded  to 
acquire  and  include  the  additional  information. 

The  format  established  by  MIL-STD-490  was  followed  in  all  phases 
of  the  preparation  of  the  document.  Close  attention  was  paid  to  the  num¬ 
bering,  identification  and  placement  of  all  paragraphs,  figures  and  tables. 

Hie  editing  staff  then  submitted  a  draft  of  the  rewritten  document 
for  the  responsible  engineer’s  appraisal.  This  event  was  very  significant 
because  the  personnel  who  were  involved  with  building  the  hardware  or 
software  that  was  being  documented  provided  valuable 
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comments  and  criticisms  that  truly  improved  the  quality  of  the  document. 

After  these  suggestions  had  been  incorporated,  the  final  copy  was  prepared, 
including  a  title  page,  table  of  contents,  list  of  figures  and  list  of  tables. 
Each  page  was  numbered  and  identified  in  the  upper  right  corner  with 

the  specification  number  and  date.  The  document  was  printed,  and  the 
copies  necessary  for  the  review  team  members  were  delivered, 

Generally,  a  member  of  the  documentation  team  participated  in 
the  review  of  the  document,  attending  the  initial,  preliminary  and  final 
review  meetings.  Careful  records  of  the  comments  and  suggestions  of  the 
review  team  members  were  kept,  and  the  document  was  revised  accordingly 
before  the  final  review  and  acceptance  of  the  document. 

4. 4. 1.2  Documents  Edited/Rewritten 
During  the  contract  forty-nine  documents  were  edited  and  then  partially 

or  totally  rewritten. 

4.4.2  Format  Editing/Proofreading 
The  contractor  shall  edit  and  proofread  pages  of  DAIS  hardware 

and  software  specifications ,  manuals  and  plans.  Primary  emphasis  is  on 
format,  compliance  with  MIL-STD  483  and  4-90  and  the  correction  of  figures 
and  drawings . 

4. 4.2.1  Editing/Proofreading 

Using  the  standards  established  by  the  Configuration  Management 
Office  (CMO)  and  MIL-STD-483  and  -490,  the  editing  team  examined  the 
appointed  document  page  by  page. 


Each  document  was  assigned  a  specification  number  and  an  approved 


title  by  the  CMO.  Revisions  vere  denoted  by  the  addition  of  a  letter  to 
the  specification  number  (e.g.,  SA123^56A  -  meaning  first  revision).  The 
specification  heading,  title,  number,  date  and  appropriate  signatures  vere 
checked  on  the  title  page.  The  documents  vere  checked  for  a  detailed  table 
of  contents,  list  of  figures  and  list  of  tables,  noting  accurately  the  cor¬ 
responding  pages.  Each  page  of  the  document  must  have  the  specification 
number  and  date  at  the  top  right,  a  page  number  at  the  lover  center  and 
must  fit  into  the  specified  DAIS  margins. 

The  text  vas  checked  to  insure  it  contained  the  sections  generally 
outlined  in  MIL-STDS.  The  paragraphs  had  to  conform  in  numbering,  identi¬ 
fication  and  contents  to  the  requirements  further  delineated  in  the 
appendices  of  MIL-STD-U83  and  -  U90.  The  proofreader  had  to  be  satisfied 
that  all  the  essential  information  vas  present. 

Figures  and  tables  should  be  placed  vithin  or  immediately  follov- 
ing  the  paragraphs  containing  reference  to  them.  If  this  interfered  vith 
correct  sequencing  of  paragraphs  and  caused  difficulty  in  understanding  or 
interpretation,  they  vere  placed  in  numerical  sequence  at  the  end  of  the 
specification.  Tables  had  to  be  boxed,  ruled  and  numbered  consecutively 
with  Roman  numerals ,  The  table  number  and  title  had  to  be  placed  above 
the  table.  Figures  had  to  be  titled  and  numbered  consecutively  vith  Arabic 
numerals  in  the  order  in  which  they  are  initially  referenced  in  the  text. 

The  figure  number  and  title  had  to  be  at  the  bottom  of  the  figure. 

Any  deviation  from  the  established  standards  vas  fully  explained 
in  section  6.0,  NOTES. 

After  the  proofreading  of  the  document  had  been  completed,  a 
letter  of  comment  vas  sent  to  the  contract  monitor.  An  example  of  this 


39 


letter  is  contained  in  Figure  17. 

4. 4.2.2  Documents  Edited/Froofread 

During  the  contract,  fifty-three  (53)  documents  were  edited/proof¬ 
read  to  insure  compliance  with  the  appropriate  MIL-STD. 

4.5  Audita  (Task  5) 

The  contractor  shall  perform  the  hardware  and  software  audits 
listed  helow.  All  audits  are  to  conform  to  MIL-STD  1521  Technical  Reviews 
and  Audits  for  Systems  Equipment  and  Computer  Programs  for  Systems  Equipment 
and  Computer  Programs .  A  separate  report  will  be  written  at  conclusion  of 
each  audit  in  accordance  with  the  data  item  specification,  the  CDRL. 

4.5.1  Physical  Audit  of  Universal  Remote  Terminal  (URT) 

* 

The  contractor  shall  perform  a  physical  audit  on  the  UPT  or  its 
equivalent.  The  URT  has  four  6"  by  12"  cards  with  approximately  175  to  200 
chips  per  board. 

This  physical  audit  was  performed  on  the  Controls  and  Display 
Control  Panel  which  has  twelve  U"  by  6"  cards  with  approximately  Uo  chips 
per  board  and  associated  wire  lists.  The  drawing  package  contained  101  sheets. 
U.5. 1.1  Hardware  Physical  Configuration  Audit 

To  accomplish  the  physical  audit  the  audit  team  developed  a 
physical  cross-check  list.  In  general,  this  was  accomplished  by  reviewing 
all  documentation  on  the  Cl  and  locating  any  information  about  the  physical 
aspects  of  the  hardware,  such  as;  number  of  parts,  type  of  parts,  connection 
of  parts ,  mountings ,  etc . 

The  hardware  drawings  were  checked  for  accuracy  to  ensure  that 
they  adequately  described  the  equipment.  For  this  check  the  following 
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MEMO  FOR  THE  RECORD 


TO:  Contractor  Monitor 

SUBJECT:  Audit  of  the  Bus  Monitor  Unit 

An  audit  of  the  Bus  Monitor  Unit  SAOOOOOOA  has  revealed  the  fol¬ 
lowing  discrepancies: 

la.  Title  page  is  incorrect.  A  revision  shall  be  denoted  with 

an  alphabetic  letter  starting  with  "A"  for  the  first  revision. 
Type  designator  code  is  missing. 

b.  All  paragraph  identification  lines  shall  be  underlined. 

c.  Footnotes  to  a  table  or  figure  shall  be  placed  below  the 
table  or  figure. 

d.  All  tables  shall  be  blocked  and  ruled. 

e.  Table  numbers  shall  be  in  Roman  numerals. 

f.  Some  paragraph  numbering  is  out  of  sequence. 

g.  The  flowchart  in  paragraph  3.2.7  does  not  have  the  direction 
of  flow  labeled,  nor  was  there  a  figure  number,  title  or  page 
number . 

h.  Section  6.0,  "Notes",  shall  contain  a  specific  paragraph  con¬ 
cerning  the  revision  as  outlined  MIL-STD-L90. 

(Contractor  Name) 

DAIS  Project  Manager 

cc:  (responsible  engineer) 

Figure  17.  LETTER  OF  COMMENT 


minimum  information  was  recorded  for  each  drawing: 

Drawing  number 

Revision  number 

Date  of  drawing  approval 

Number  of  sheets 

Dis crepancies /Comments 

As  a  minimum,  the  following  inspections  were  accomplished  for 
each  drawing: 

(1)  Examination  of  the  Cl  to  ensure  that  current  nomenclature 
descriptions,  part  numbers  and  serial  numbers  agreed  with 
the  drawings. 

(2)  Physically  checked  the  number  of  pieces  of  material  shown  on 
the  drawing  with  the  number  actually  in  the  equipment ;  e . g . , 
if  the  drawing  called  for  four  transistors  of  a  certain 
type  within  the  end  item,  this  information  was  checked. 

(3)  Recorded  the  number  and  date  of  each  attached  drawing  change 
notice. 

( U )  Noted  if  the  drawing  was  "marked  up." 

(5)  Checked  the  drawings  of  a  major  assembly  of  the  CT  for  continuity 
from  top  drawing  to  piece-part  drawing. 

(6)  In  addition,  the  auditors  checked  the  drawings  against  the  spec- 
ificatio  to  see  if  the  drawings  agreed  with  major  subsystem 
discuss  jns  of  the  specification. 


4. 5. 1.2  Physical  Comparison  of  Hardware  With  Drawings 

The  hardware  was  then  compared  to  each  drawing  in  the  drawing 
package  for  it  is  imperative  that  the  drawings  agree  with  the  actual 
hardware.  When  discrepancies  were  found  during  the  comparison,  then 
they  were  reported  in  the  Hardware  Audit  Report. 

4.5. 1.3  Audit  Summary.  Control/Display  Control  Panel.  DA501100 

The  audit  revealed  over  one  hundred  and  fifteen  discrepancies 
on  the  drawings.  These  discrepancies  were  corrected  either  by  revisions 
to  the  original  drawings  or,  if  there  were  too  many,  the  drawing  was  com¬ 
pletely  redrawn.  After  the  revised  drawings  were  reviewed  and  approved 
two  copies  of  the  large  size  drawings  were  reproduced  and  delivered  to 
the  DAIS  library.  The  drawing  package  was  reduced  to  booklet  size 
and  five  copies  delivered  to  the  DAIS  library. 

4.5. 2  Physical  Audit  of  Modular  Programmable  Display  Generator  (MPDG) 

The  contractor  shall  perform  a  physical  audit  on  the  MPDG  or  its 
equivalent.  The  MPDG  has  sixteen  different  4"  by  6"  boards  with  approxi¬ 
mately  55  chips  per  board. 

4.5.2. 1  Hardware  Physical  Configuration  Audit 

This  audit  was  conducted  in  a  manner  similar  to  that  of  the 
Control  Panels.  The  drawing  package  consisted  on  sixty- five  sheets. 

4. 5.2.2  Audit  Summary 

The  audit  revealed  over  two  hundred  and  eighty-one  discrepencies 
on  the  drawings.  These  discrepancies  were  corrected  either  by  revisions 
to  the  original  drawings  or,  if  there  were  too  many,  the  drawing  was 
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completely  redrawn.  After  the  revised  drawings  were  reviewed  and  approved,  two 
copies  were  reproduced  and  delivered  to  the  DAIS  Library*  The  entire  drawings 
package  was  reduced  to  booklet  size  and  five  copies  delivered  to  the  DAIS  Library. 
U.5.3  Physical  Audit  of  Bus  Monitor  Unit  (BMU). 

The  contractor  shall  perform  a  physical  audit  on  the  BMU  or  its 
equivalent.  The  BMU  is  of  the  same  complexity  as  the  URT.  There  are  four  6” 
by  12”  cards  with  175  to  200  chips  per  board.  This  audit  was  performed  on  the 
Control  and  Displays,  Display  Switch  Memory  Unit  (DSMU).  The  DSMU  has  thirteen 
U”  by  6”  cards  with  approximately  95  chips  per  board. 
b.5.3.1  Hardware  Physical  Configuration  Audit  (DSMU). 

This  physical  audit  was  conducted  in  a  manner  similar  to  that  of  the 
Control  Panels.  The  drawing  package  contained  thirty  six  sheets. 

U. 5-3*2  Audit  Summary  (DSMU). 

The  audit  revealed  over  two  hundred  and  ninety-one  discrepancies  on  the 
drawings.  These  discrepancies  were  corrected  either  by  revisions  to  the  original 
drawings  or,  if  there  were  too  many,  the  drawing  was  completely  redrawn.  After  the 
revised  drawings  were  reviewed  and  approved,  two  copies  were  reproduced  and 
delivered  to  the  DAIS  Library.  The  entire  drawing  package  was  reduced  to  booklet 
size  and  five  copies  delivered  to  the  DAIS  Library. 

U.5.U  Physical  Audit  of  AK/AYK-15A  DAIS  DIGITAL  PROCESSOR. 

The  contractor  shall  perform  a  physical  audit  on  the  AN/AYK-15A 
Processor  or  its  equivalent.  The  processor  has  9  different  printed  circuit  boards 
with  approximately  130  chips  per  board.  The  printed  circuit  cards  are  multi-layer. 
U.5.U.1  Audit  SuMHHtry. 

The  audit  was  performed  on  both  the  Westinghouse  Processor  and  Univac 
Performance  Monitor  Interface  Unit  (PMIU).  These  audits  revealed  one  hundred 
fifty-seven  discrepancies  on  the  processor  and  three  hundred  thirty  on  the  PMIU. 
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^•5*5  Software  Audit  of  the  Modular  Programmable  Display  Generator  (MPDQ) 
The  contractor  was  originally  to  perform  a  software  audit  of  the 
Simulated  Subsystem  Data  Formatter  (SSDF)  computer  program.  The  program  is 
resident  on  a  Digital  Equipment  Corp.  (DEC)  PDP  11/UO  computer  consisting 
of  about  U,000  lines  of  assembly  language  code. 

At  the  request  of  the  Air  Force  for  reasons  of  priority,  the  soft¬ 
ware  audit  was  performed  on  the  MPDG  computer  programs.  The  MPEG  software 
is  resident  on  the  DECsystem-10  computer  and  has  approximately  65  ,000  com¬ 
bined  lines  of  assembly  language  code  and  corresponding  data. 

The  procedures  and  findings  of  the  Physical  Configuration  Audit  (PCA) 
are  described  in  the  following  paragraphs. 

4.5»5»1  Preparatory  Audit  Procedures 

All  documentation  associated  with  the  MPDG  software  such  as  the 
Part  I  Development  Specification,  Part  II  Product  Specification,  User's 
Manual,  Interface  Control  Drawing,  Flowcharts  and  listing  were  reviewed  for 
content  to  gain  an  understanding  of  the  system  in  total  and  the  functions 
it  was  to  perform.  A  brief  description  of  each  item  is  given  below. 

U*5«5'2  Product  Specification  (Part  II  or  C5) 

•Hie  product  (or  Part  II  type)  specification  contains  technical 
information  about  the  software  Cl,  including  a  description  of  its  logic 
structure  and  functions,  data  organization,  and  interrupt  structure.  The 
level  of  detail  should  be  sufficient  to  enable  a  programmer,  with  no  pre¬ 
vious  exposure  to  the  software,  to  understand  readily  the  internal  operation 
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of  the  software. 


U.5.5.3  User *3  Manual 


The  User's  Manual  Is  to  provide  potential  software  Cl  users  with 
the  necessary  instructions  for  operating  the  software  Cl.  The  manual 
content  and  format  are  specifically  designed  to  meet  the  needs  of  the 
intended  user.  User's  Manuals  are  typically  written  to  be  as  self- 
contained  as  possible  with  few  references  to  other  documents.  They  are 
written  at  the  level  of  understanding  and  comprehension  appropriate  to  the 
intended  users  and  usually  consist  of  lists  of  steps  and  procedures  to  be 
followed.  The  audit  of  the  User's  Manual  is  pe.  formed  prior  to  or  in  con¬ 
junction  with  the  final  acceptance  testing, 

^•5.5*^  Interface  Control  Document  (ICD) 

The  Interface  Control  Document  contains  the  physical  and  functional 
interface  requirements  of  a  software  Cl  which  affect  the  design  or  opera¬ 
tion  of  co-functioning  software  CIs  to  control  interface  designs  for  the 
purpose  of  minimizing  changes  to  software  Cl  requirements,  and  to  communicate 
design  decisions  and  changes  to  participating  groups. 

U. 5.5.5  Flowcharts 

The  flowcharts  submitted  for  audit  should  be  from  the  latest  release 
of  the  product  specification  and  must  reflect  the  source  code  of  the 
software's  most  current  version.  The  flowcharts  should  conform  to  the 
military  standards  in  format.  Flowcharts  should  easily  show  the  structure 
and  function  of  the  source  code. 

U. 5.5*6  Listings 

Listings  submitted  for  audit  shall  be  of  the  latest  software  version 
in  use.  Listings  should  be  commented  in  such  a  way  that  someone  unfamiliar 
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with  the  program  language  used  can  examine  the  listing  and  the  flowcharts 
and  understand  the  function  of  the  code. 

*♦•5.5.7  Audit  Procedures 

The  PCA  effectiveness  greatly  depended  on  the  content  of  the  docu¬ 
mentation  of  the  software  Cl  to  be  audited.  The  software  Cl  could  only 
audited  in  as  much  detail  as  the  documentation  provided. 

The  PCA  consisted  of  four  procedures  (Figure  18):  (l)  data  gather¬ 

ing,  (2)  developing  an  audit  checklist,  (3)  physcial  cross-checking,  and 
(U)  algorithm  analysis.  These  procedures  were  followed  for  each  document 
related  to  the  software  Cl  to  be  audited. 

U. 5. 5.7.1  Data  Gathering 

To  audit  the  software  Cl  against  a  particular  document,  it  was 
necessary  to  gather  two  data  items.  The  first  was  a  final  copy  of  the 
document.  It  was  important  that  draft  copies  and  preliminary  versions  of 
the  document  not  be  used  for  a  formal  PCA.  This  ensured  that  the  entire 
document  was  audited  in  the  form  in  which  it  had  been  released. 

The  second  data  item  required  was  the  most  current  listing  of  the 
source  code  for  the  software  Cl.  This  was  an  assembler  listing  generated 
by  the  audit  team  from  the  software  Cl's  allocated  baseline,  which  was  used 
for  the  final  acceptance  testing.  The  data  and  time  at  which  the  copy  was 
made,  along  with  the  date  and  time  at  which  the  source  code  was  last  modi¬ 
fied  (if  available),  was  also  recorded.  This  then  represented  an  informal 
baseline  to  which  all  audit  results  were  related. 

U.5.$.7.2  Developing  the  Audit  Checklist  for  Software 

The  audit  checklist  was  created  from  the  Product  Specification 


being  used  in  the  audit.  It  consisted  of  a  list  of  specific  elements  of  the 


NOTI:  THK  TASKS  WITHIN  THE  BROKEN  LINED  BOX  CAN  BE 

PERFORMED  IN  PARALLEL  BUT  MUST  BE  DONE  BEFORE 
THE  OUTPUT  AUDIT  REPORT 


Figure  18.  AUDIT  FLOW  DIAGRAM 


code  which  were  examined  to  determine  their  relationship  to  the  document. 

The  contents  of  the  product  specification  were  audited  against 
the  latest  software  version  to  determine  the  accuracy  of  the  specification. 


The  following  items  in  particular  were  checked  for  validity: 

1)  All  file  names 

2)  Variable  names 

3)  Subroutine  mnemonics 

h )  Algorithms 

5)  Data  Set  Definitions 

6 )  Data  Tables 

•  Matrix  sizes 

•  Word  values  and  proper  index 

•  '  Base  Page  items 

•  Non-Base  Page  items 

7)  Flowcharts  for  accurate  representation  of  source  code. 

8)  Text  for  accurate  descriptions. 

U, 5. 5.7.3  Physical  Cross-Checking 

Physical  cross-checking  of  the  Part  I  type  and  Part  II  type 
specifications  and  ICDs  consisted  of  two  activities.  The  first  was  to 
go  through  the  document  and  verify  that  each  of  the  routines  described 
corresponded  to  routines  which  actually  existed  within  the  source  code. 

The  second  was  to  verify  that  the  storage  allocations  described  in  the 
document  (i.e.,  common  block  names,  variable  names,  etc-)  corresponded  to 
those  actually  used  in  the  source  code.  All  discrepancies  found  during  the 
physical  cross-check  were  noted  in  the  Audit  Report. 

Ut5.5,7,4  Algorithm  Analysis 

The  purpose  of  the  algorithm  analysis  was  to  verify  that  the 
logic  presented  in  the  flowcharts  of  a  Part  I  type  of  Part  II  type 
specification  correctly  represented  the  logic  implemented  in  the  source 
code.  Algorithm  analysis  was  also  used  to  verify  that  formulas  and  equa¬ 
tions  were  properly  implemented.  The  results  of  this  analysis  were  in  the 


Audit  Report. 
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U . 5 • 5 • 8  Summary  of  Audit  Results 

Below  is  a  partial  listing  of  some  typical  errors  which  were 
noted  during  the  PCA: 

1)  Flowcharts : 

a)  Some  were  totally  inaccurate  indicating  the  software  had 
been  greatly  modified  since  the  creation  of  the  flowchart. 

b)  Subroutines  were  either  omitted  or  were  functionally 
described  but  not  denoted  as  subroutines. 

c )  Typos  were  noted  in  algorithms. 

d)  In  some  cases,  only  1  flowchart  was  given  for  2  different 
routines  (MPDG1/MPDG2)  that  were  similar  but  not  identical. 

2)  Erroneous  matrix  size  values. 

3)  Table  word  lengths  were  found  in  error  as  were  some  word  values. 

U)  Only  1  base  page  table  was  given  to  represent  both  MPDG1  and 
MPDG2  which  proved  inadequate. 

U, 5.5.9  Audit  Report 

The  findings  of  the  PCA  were  compiled  into  a  final  report  and 
delivered  to  the  Air  Force.  Due  to  the  significant  error  factor,  especially 
in  flowcharts  (greater  them  50%) ,  the  following  contractor  recommendations 


were  made: 

1)  Retire  the  original  C-5  spec. 

2)  Generate  an  individual  C-5  spec,  for  MPDG1  and  another  for  MPDG2. 

3)  Prepare  an  alphabetized  cross  reference  table  for  file  names  with 
their  associated  subroutines  and  vice-versa. 

U)  Rewrite  all  flowcharts  and  place  the  subroutine  file  name  with  the 
flowchart  title. 

(Note:  Items  3  and  h  were  prompted  due  to  an  innumerable  number  of  sub¬ 
routines,  many  with  similar  mnemonics,  which  made  source  tracking 
very  difficult.  ) 
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Upon  concurrence  of  the  responsible  engineer  and  the  program 


office,  production  of  the  new  C-5  specifications  was  begun,  correcting  all 
discrepancies  noted  in  the  PCA  and  generating  nc-/  flowcharts  for  all 
routines . 
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U.6  PAIS  Control  Board  Support 

The  contractor  shall  have  the  responsibility  of  providing  the 
Recording  Secretary  for  the  DAIS  Configuration  Control  Board,  Problem 
Report  Board  and  the  Test  Control  Board.  The  contractor  shall  write, 
type  and  distribute  the  minutes  of  all  three  boards . 

U.6. 1  General 

Configuration  Control  is  a  major  CM  function.  It  is  the  process 
of  documenting  changes  to  established  baselines  to  provide  the  necessary 
visibility  into  the  development  process  at  a  given  moment.  Once  a  base¬ 
line  is  frozen,  proposed  and  approved,  changes  to  it  must  be  well- identified 
and  fully  considered  within  the  perspective  of  the  total  program.  When  the 
product  baseline  is  established,  all  changes,  no  matter  how  small,  must 
be  processed  through  a  well-defined  and  duly  constituted  change  control 
process.  Any  change  when  viewed  by  itself  may  seem  trivial,  but  numerous 
changes  require  orderly  procedures  and  careful  bookkeeping  to  maintain 
knowledge  and  control  of  the  actual  configuration. 

The  contractor  performed  this  function  for  the  DAIS  Program 
Branch  by  providing  the  recording  secretary  for  the  Control  Board  activities. 
In  order  to  fully  understand  the  magnitude  of  this  effort.  It  would  be 
wise  to  review  the  structure  of  the  Control  Board  function  as  practiced  by 
the  DAIS  Program  Branch. 

U.6.2  DAIS  Control  Boards  &  C.M.O. 

Within  the  DAIS  Program  Branch,  the  group  that  administered  change 
control  was  known  as  the  Configuration  Control  Board  (CCB).  The  CCB  was  the 
oily  agency  authorized  to  act  on  proposed  changes  to  the  baseline 
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configuration.  The  primary  function  of  the  CCB  vas  to  control  the  baseline, 

and  in  the  DAIS  Branch  it  vas  carried  out  by  the  following: 

Document  Control  Board  (DCB) 

Problem  Report  Board  (PRB) 

Test  Control  Board  (TCB) 

Product  Control  Board  (PCB) 

Configuration  Management  Office  (CMO) 

The  DAIS  Program  Branch  organizational  functions  are  shown  in 
Figure  19.  The  activities  and  procedures  utilized  by  the  CCB  and  the  CMO 
to  carry  out  these  functions  will  be  discussed  in  the  following  sections. 
L.6.3  Documentation  Control  Board  (DCB) 


The  Documentation  Control  Board’s  principal  responsibility  cen¬ 
tered  around  the  final  approval  of  all  documents  that  were  in  the  DAIS 
system.  Additional  responsibilities  of  the  Board  included  the  selection 
of  review  teams,  approval  of  changes  to  documents  via  SCN/DCN,  review  of 
audit  reports  of  both  hardware  and  software,  and  the  appointment  of  ad  hoc 
committees,  as  required  (e.g..  Life  Cycle  Cost  Committee). 

The  membership  of  the  Board  consisted  of: 

Branch  Chief  -  Chairman 

CMO  Manager  -  Secretary 

DAIS  Group  Leaders 

SITC  Contractor 

Documentation  Contractor 

AAF  Representative 

DAIS  Contractors  (as  required) 

This  board  met  every  two  weeks  and/or  as  required  to  review 
urgent  subjects. 
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k .  6 . 3 . 1  Documentation  Data  Flow 


Specifications  prepared  by  in-house  elements  or  by  DAIS  con¬ 
tractors  were  submitted  to  the  DCB  for  review  and  approval  action.  Each 
specification  underwent  extensive  analysis ,  which  involved  considerable 
time.  Upon  becoming  an  action  item  for  the  DCB  agenda,  the  DCB  would  review 
the  schedules  and  general  needs  for  the  document  within  the  system.  The 
DCB  would  then  appoint  a  review  team  and  assign  the  scheduled  initial  review 
date.  Formal  correspondence,  signed  by  the  DAIS  Branch  Chief,  would  be 
issued,  identifying  the  team  members  and  schedule  involved.  Final  DCB  action 
would  result  from  the  review  team  recommendations .  Concurrent  with  review 
team  effort,  the  specification  would  also  be  given  an  editorial  review 
(for  compliance  with  MIL-STD-U90)  by  the  CMC  technical  editor. 

^.6.3.2  DCB  Submission  Guidelines 

In  order  to  have  a  document  accepted  into  the  DAIS  documentation 
system,  there  were  definite  procedures  to  be  followed.  The  detailed  steps 
were  as  follows.  The  responsible  engineer  had  to  obtain  a  DAIS  document 
number,  which  required  him  to  submit  a  written  request  containing  the  docu¬ 
ment  title,  scope  statement,  draft  due  date  and  responsible  engineer/contractor. 
When  the  CMO  received  the  request,  a  number  was  assigned  and  a  CCB  Directive 
would  be  submitted  for  approval  by  the  Board.  Once  approved,  the  CMO  then 
updated  MA  100100,  DAIS  Document  Description  Plan,  PA  OOOUOO ,  DAIS  Document 
Status  Plan,  and  DA  100100,  DAIS  Specification  Tree.  After  the  document  was 
developed,  the  steps  as  listed  below  had  to  be  accomplished  to  initiate  the 
document  review  cycle. 
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Document s/SCNs/DCNs/ for  initial  submission 
•  Submit  to  CMO: 

•  Original  Document /SCN/DCN 

•  Completed  Form  DAIS  78-03 

•  Completed  Form  DD  1696  for  SCN 

•  Completed  Form  DAIS  78-02  for  DCN 

•  Copy  of  Document /SCN /DCN  for  each  Review  Team 
Member  plus  one  for  DCB 

k.6.3.3  Document  Review  Cycle 

The  actions  taken  by  the  DCB  upon  receipt  of  the  document  are 
outlined  in  Figure  20.  Depending  upon  the  workload  and  the  priority  assigned 
to  the  document ,  the  DCB  would  activate  the  review  team  which  placed  the 
document  in  the  review  cycle.  The  details  of  the  review  cycle  are  shown 
in  Figure  21.  Depending  upon  the  size  and  complexity  of  the  document,  this 
cycle  could  take  up  to  six  months  to  complete.  The  key  to  efficient,  success¬ 
ful  completion  of  the  cycle  was  the  review  team  leader.  His  duties  are 
contained  in  Figure  22.  The  progress  of  the  document  through  its  review 
cycle  was  tracked  by  the  DCB  through  means  of  Attachment  1  to  the  DCB  minutes, 
which  was  reviewed  and  updated  at  each  DCB  meeting. 

U.6.3.1*  Document  Control  Board  Support 

The  contractor  provided  the  secretariat  support  for  the  DCB  and 
all  of  its  allied  functions  described  above.  This  responsibility  included 
the  establishing  and  maintaining  of  all  configuration  control  procedures. 

It  was  most  important  that  each  document  be  tracked  from  initiation  through 
receipt  to  document  approval  and  publication.  For  this  purpose*  the  tracking 
system  had  to  be  maintained  to  give  real-time  status  of  documents  processed 
by  the  DCB.  This  included  preparing  the  agenda  for  the  DCB  meeting,  recording 
all  actions  taken  during  the  meeting,  coordination  with  other  contractors 
and  DAIS  personnel  (to  insure  that  accurate  and  timely  data  were  included 
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DOCUMENT  REVIEW  CYCLE  (1  OF  2) 
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in  the  minutes),  preparation,  approval,  printing  and  distribution  of  the 
minutes . 


Additional  responsibilities  of  the  recording  secretariat  were: 

•  Maintenance  of  DCB  Minutes  file 

•  Maintenance  of  CCB  Directive  file 

•  Maintenance  of  PAOOUOO  DAIS  Document  Status  Plan 

•  Updating  of  MA  100100  DAIS  Document  Description  Manual 

•  Maintenance  of  document  avaiting-review  file 

•  Maintenance  of  document  in-review  file 

•  Maintenance  of  file  for  all  correspondence  to  the 
DCB 

•  Providing  the  central,  point  of  contact  for  outside 
government  agencies  and  contractor  personnel 

U.6.3.5  Document  Control  Board  Activities 


During  the  life  of  the  contract,  the  contractor  provided  the 

t 

above  mentioned  support  for  3^  Document  Control  Board  (DCB)  meetings 
before  the  DCB  was  discontinued.  The  DCB  was  replaced  by  the  MIL  STD 
Conversion  Team  ana  the  contractor  provided  support  for  13  such  meetings. 

Also,  during  this  period  185  documents  were  processed  through  the  document 

i 

review  cycle  and  released  for  distribution.  j 

U.6.U  Problem  Report  Working  Group  | 

The  Problem  Report  Working  Group  (PRWG),  chaired  by  the  Test  I 

* 

£ 

Director,  consisted  of  members  designated  as  problem  coordinators  (PC)  * 

i 

for  the  following  areas :  ^ 

•  Real-Time  Support  Software 

•  System/Facility 

•  Controls  and  Displays  I 

•  Mission  Software /Non-Real-Time  Support  Software  ! 

•  Support  Hardware 

•  Core  Elements 
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A  SITC  representative,  acting  as  recorder,  vas  also  a  member  of  the  PRWG. 

The  PRWG  met  weekly  to  review  the  status  of  all  outstanding 
Problem  Reports,  to  ensure  appropriate  action  was  being  taken.  This  group 
also  was  responsible  for  assigning  new  problems  to  a  responsible  engineer 
for  resolution.  Any  problems  that  were  determined  to  be  beyond  the  charter 
of  the  PRWG  (e.g.,  those  impacting  cost,  schedule,  etc.)  were  elevated  by 
the  PRWG  to  the  Problem  Report  Board.  It  should  be  noted  that,  in  addition 
to  PRWG,  any  individual  who  felt  that  a  problem  should  be  elevated  to  the 
PRB  could  do  so  by  either  personally  sending  a  memorandum  to  the  PRB  identi¬ 
fying  the  problem  or  by  contacting  the  responsible  problem  coordinator  and 
requesting  that  he  elevate  the  problem. 

U.6.U.1  Problem  Report  Working  Group  Chairman  Tasks 

Scheduled  meetings 

Assigned  responsible  Engineer 

Assigned  priorities 

Monitored  status  of  Problem  Reports 

Coordinated  the  effort  of  different  Groups 

Closed  out  Problem  Reports 

Elevated  PR  to  PRB 

Published  Weekly  Status  Log 

Submitted  Document  Change  Requirements  to  PRB 

U.6.5  Problem  Report  Board  (PRB) 

This  Board  facilitated  the  handling  of  problems  that  were  out¬ 
side  the  charter  of  the  standing  Problem  Report  Working  Group  (PRWG).  The 
PRB  Membership  consisted  of  the  following  members: 

Branch  Chief  -  Chairman 
CMO  Manager  -  Secretary 
DAIS  Group  Leaders 
ITB/STS  Test  Director 
SITC  Contractor 
AAF  Representative 
Documentation  Contractor 
DAIS  Contractors  (as  required) 
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In  order  to  resolve  Problem  Reports  that  were  elevated  to  the  FRB , 
the  PRB  appointed  Problem  Report  Groups  ( PRGs )  to  thoroughly  review  the 
problem  report  and  submit  recommendations  for  appropriate  action.  The 
status  of  these  groups  was  tracked  through  the  use  of  an  attachment  to  the 
PRB  minutes.  When  a  group  had  completed  its  work,  it  was  normally  disbanded 

by  the  Board. 

This  Board  met  every  two  weeks  after  the  DCB  meeting  or  on  an 
as-required  basis. 

U.6.5.1  Problem  Report  Procedures 

A  Problem  Report  vas  written  for  a  milestone,  task,  or  technical 
problem  of  sufficient  significance  to  require  control  and  follow-up  to 
ensure  completion  of  the  action.  Problem  Reports  were  listed  on  the  Problem 
Report  Log,  to  provide  proper  tracking  of  action  required  and  performed 
to  resolve  the  problems.  The  Problem  Report  Flow  is  shown  in  Figure  23. 
U.6.5.2  Problem  Report  Board  Support 

The  contractor  served  as  secretariat  to  the  PRB,  which  included 
recording  the  minutes  of  thirty-five  meetings,  effecting  the  necessary  coordi¬ 
nation  to  ensure  that  the  minutes  accurately  reflected  the  Board  proceedings , 

published  and  distributed  the  minutes.  Also,  the  secretariat  assisted  in 
developing  the  combined  Problem  Report  form  and  in  writing  DCN  #1  to  the 
Configuration  Management  Plan,  to  Incorporate  the  new  Problem  Report 
Procedure.  Also,  this  support  required  the  maintenance  of  a  file  for  all 
opened  and  closed  Problem  Report  forms.  During  the  period  of  the  contract 
over  U6l  Problem  Reports  were  processed.  Of  this  number ,  6U  were  elevated 
to  the  PRB  for  resolution.  Sixteen  teams  were  formed  to  work  these  problems. 
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k.6.6  Test  Control  Board  (TCB) 

This  Board  was  responsible  for  organizing  Test  Working  Groups 
(TWGs)  to  ensure  that  integration  testing  was  accomplished  efficiently 
and  in  a  timely  manner.  The  requirement  for  the  TCB  was  generated  by  the 
fact  that  much  of  the  testing  performed  on  the  STS/ITB .  as  the  DAIS  program 
matured  cut  across  several  areas  (e.g.,  mission  software,  C&D,  models,  etc.) 
and  was  performed  on  a  functional  basis  (e.g.,  weapon  delivery,  steering, 
etc.).  This  type  of  testing  required  participation  by  personnel  from  each 
area  to  support  the  tests  and  required  judicious  planning  of  the  limited 
AFWAL/AAAS  and  contractor  personnel  resources  to  effectively  perform  the 
integration  and  test  activities . 


The  members  of  the  TCB  were : 

•  Branch  Chief  -  Chairman 

•  CMC  Manager  -  Secretary 

•  DAIS  Group  Leaders 

•  ITB/STS  Test  Director 

•  SITC  Contractor 

•  Documentation  Contractor 

•  DAIS  Contractors  (as  required) 
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The  tentative  schedule  of  Board  meetings  was  every  two  weeks  at 
the  conclusion  of  the  DCB  meeting. 

^.6.6.1  Test  Control  Board  Tasks 

The  principal  tasks  of  the  TCB  were  as  follows : 

•  Implemented  DAIS  demonstration  objectives  (interim  and  final) 
and  tasks,  as  established  by  DAIS  Program  Branch  Chief 

•  Reviewed  and  approved  Integration  and  Test  Concepts  and  Plans 

•  Formulated  each  TWG,  assigned  members  and  tasks 

•  Approved  TWG  schedules.  Integration  and  Test  Activities 

•  Reviewed  status  and  progress  of  TWGs 

•  Established  priorities 

•  Resolved  Problem  Reports  that  specifically  affected  Test 
Planning,  TWG  assignments  of  Test  Schedules  and  Activities 

U.6.6.2  Test  Working  Groups  (TWGs)  Tasks 

•  Performed  Integration  and  Test  Activities  as  assigned  by  TCB 

•  Prepared  and  submitted  to  Test  Director  (TD)  an  ITB/STS 
Schedule  Request  defining  test  time  and  configuration  required 

•  Notified  TD  when  assigned  time  could  not  be  used 

•  Prepared  checklists  for  TCB  approval 

•  Prepared  Problem  Reports,  as  required,  for  submittal  to  TD 

•  Prepared  Test  Reports  containing  test  checklist ,  test  conclusions 
and  exceptions  at  the  end  of  the  test  for  the  TCB 

In  order  to  accomplish  the  above  tasks,  the  typical  flow  of  a 

test,  from  conception  of  a  requirement  to  the  submittal  of  a  test  report, 

is  shown  in  Figure  2U.  The  progress  of  the  tests  was  tracked  by  the  TCB 

by  use  of  an  attachment  to  the  TCB  minutes.  Also,  the  team  leader  could 

be  called  upon  to  give  a  verbal  progress  report  during  a  TCB  meeting  or  at 

a  special  meeting  if  the  situation  dictated. 
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INTEGRATION  TESTING 

_ I  1TATU8  REPORT 
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Figure  24.  Typical  Flow  01  A  Taat  (coat’d) 


U . 6 . 6 . 3  Test  Control  Board  Support 

The  contractor  served  as  the  secretariat  to  the  TCB.  In  this 
capacity,  minutes  were  recorded  and  necessary  coordination  was  performed 
to  ensure  that  accurate  information  was  contained  in  the  minutes.  Also, 
the  minutes  were  published  and  distributed,  and  a  file  was  maintained  on 
all  correspondence  to  and  from  the  TCB.  During  the  period  of  the  contract 
six  TCB  meetings  were  conducted  prior  to  its  dissolution. 

The  Test  Control  Board  provided  adequate  configuration  control 
over  the  testing  that  vas  being  accomplished.  However  these  activities 
revealed  problems  that  were  occuring  due  to  the  lack  of  proper  configura¬ 
tion  control  over  DAIS  software  and  hardware.  Therefore,  a  new  board, 
the  Product  Control  Board  (PCB)  was  formed.  The  PCB  had  the  expanded  charter 
to  exercise  control  of  the  DAIS  hardware ,  software  and  testing. 

U.6.7  Product  Control  Board  (PCB) 

The  Product  Control  Board *s  principal  responsibility  centered 
around  identifying,  controlling,  recording  and  authorizing  changes  to  the 
Software  Test  Stand  (STS)  and  Integrated  Test  Bed  (ITB)  hardware  and  software. 
The  integration  testing  was  controlled  in  the  same  manner  as  It  was 
accomplished  under  the  dissolved  Test  Control  Board. 

The  members  of  the  TCB  were: 

•  Branch  Chief  -  Chairman 

•  CMO  Manager  -  Secretary 

•  DAIS  Group  Leaders 

•  ITB /STS  Test  Director 

•  SITC  Contractor 

•  Documentation  Contractor 

•  DAIS  Contractors  (as  required) 
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The  tentative  schedule  of  Board  meetings  was  every  two  weeks  at 


the  conclusion  of  the  PRB  meeting. 

U.6.7.1  Hardware/ Software  Configuration  Control  Procedures 

The  AFWAL/AAAS  Test  Director*  with  suDport  from  the  SITC  contractor, 
was  responsible  for  maintaining  control  of  the  STS  and  ITB  hardware  and 
software  configurations .  The  Test  Director  Tasks  are  outlined  in  Table  III. 

A  set  of  configuration  status  logs  was  utilized  to  track  the  configuration 
changes  as  follows :  two  master  logs ,  one  each  for  STS  equipment  configuration 
and  ITB  equipment  configuartion ;  a  set  of  status  logs  for  each  equipment 
and  support  software  end  item. 

Changes  to  the  ITB  and  STS  items  had  to  be  coordinated  with  and 
approved  by  the  Test  Director  and  recorded  in  the  specific  logic  as  summarized 
below: 

1.  STS  and  ITB  Equipment  Configurations 

a.  Minor  Changes.  Any  minor  changes  in  the  configurations 
(e.g.,  bus  patch  panel  and  CIU  patch  panel)  were  verbally 
coordinated  with  the  Test  Director. 

b.  Major  Changes  -  Hardware  Relocations.  All  equipment  reloca¬ 
tions  within  STS  or  ITB,  or  removal  from  or  incorporation 
into  STS  or  ITB,  had  to  be  approved  by  the  Test  Director  and 
recorded  in  the  Master  STS  or  ITB  log.  The  Test  Director 
scheduled  the  movement  of  the  equipment  in  order  to  minimize 
impact  on  either  STS  or  ITB  activities.  Equipment  Allocation 
Control  Flow  is  depicted  in  Figure  25. 

2.  Equipment  End  Item  Modifications 

a.  Permanent  Hardware  Configuration  Changes.  All  permanent 
changes  were  documented  and  approved  by  the  CCB  in  a  CCB 
directive.  The  modifications  were  usually  incorporated  and 
tested  offline  in  the  stand-alone  test  area.  Relocation  into 
the  STS  or  ITB  was  coordinated  with  the  Test  Director  as 
described  in  1(a)  above.  The  changes  were  also  recorded  in  the 

equipment  end  item  status  log. 
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Figure  25.  EQUIPMENT  ALLOCATION  CONTROL  FLOW 


b.  Temporary  Hardware  Configuration  Changes.  Temporary  hardware 
changes  were  incorporated  into  a  specific  end  item  to  support 
problem  isolation  or  as  temporary  fixes  for  critical  problems. 
This  could  be  initiated  as  a  result  of  a  problem  report.  A 
description  of  the  temporary  modification  and  instructions  on 
how  to  return  the  end  item  to  the  prior  configuration  was 
attached  to  the  problem  report.  The  Teat  Director  scheduled 
and  approved  the  temporary  change,  recorded  the  change  in  the 
Master  STS  or  ITB  log  book  and  respective  equipment  log. 

3.  Real-Time  Support  Software  Configuration  Control 


a.  Enhancements  and  Modifications.  Developers  enhanced  and 
modified  their  software  from  a  "Private  Area"  file  or  disk  area. 

All  changes  were  documented,  tested,  and  submitted  to  the  Test  ^ 

Director  for  approval.  After  Test  Director  approval,  the  PCB  # 

was  notified  and  the  new  version  was  moved  into  a  "New  Version  || 

Area"  disk  or  file.  j 

b.  Maintaining  "Official  Copy".  At  turnover  of  the  "New  Version", 
a  series  of  tests  were  performed  to  show  the  software  met  all 
of  its  system  requirements .  All  errors  uncovered  were  reported 
in  Problem  Reports.  A  "New  Version"  was  then  turned  over  to 
the  Test  Director  for  retest. 

The  Test  Director  notified  the  PCB  after  successfully  complet¬ 
ing  these  tests  and  the  PCB  approved  movement  of  the  new  ver¬ 
sion  to  the  "Official  Version  Area"  as  shown  in  Figure  2 6. 

Backup  of  the  "Official  Version  Area"  on  separate  disks  or  tapes 

was  maintained  bv  the  S/W  CMO.  The  S/W  CMO  recorded 
the  new  version  change  in  the  respective  log. 

All  users  used  the  "New  Version"  or  "Official  Version",  and 
reported  all  problems  in  Problem  Reports  to  the  Test  Director. 

The  "Official  Version"  was  used  for  demonstrations. 


U.6.7.2  Product  Control  Board  Support 

During  the  period  of  the  contract  there  were  25  meetings  of  the 
PCB;  70  backup  tapes  of  the  Offical  Version  Area  were  made.  The  PCB  was 
dissolved  once  configuration  control  was  gained  and  the  system  running 
smoothly.  However,  to  insure  it  was  properly  maintained  the  Hardware  and 
Software  Logs  were  placed  under  the  PRB  and  all  changes  were  briefed  at  the 
PRB  meetings. 
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The  contractor  shall  provide  150,000  copies  of  pages  of 
documents  as  requested  by  the  Configuration  Management  Office.  These  copies 
are  used  for  reviews  and  fast  turn-around  requirements.  Whenever  possible 


the  Air  Force  printing  office  or  other  AFAL  reproduction  facilities  are 
used.  Use  of  AF  printing  facilities  must  be  coordinated  with  the  Project 
Monitor.  PCO  approval  is  also  required. 

U.7.1  Copying  Request  Flow 

The  originator  of  a  request  for  copying  support  made  the  request 
through  the  CMC  office  and  it  specified  the  document  number,  title  and  date. 
The  need  date  was  stated  to  assist  the  CMO  in  determining  if  the  copying 
could  be  accomplished  by  the  Air  Force  printing  office  or  at  the  contractor 
facility.  The  criteria  used  by  the  CMO  was:  If  the  copies  weren't  needed 
for  two  weeks  or  more  than  ten  copies  were  needed  and  the  document  was  larger 
than  ten  pages  then  it  could  be  accomplished  by  the  Air  Force  printing  office. 
If  a  fast  turn-around  was  required,  such  as  for  review  team  activities,  or 
if  less  than  ten  copies  or  ten  pages,  then  the  copying  Job  was  accomplished 
at  the  contractor  facility.. 
fc.7.2  Copying  Tracking 

Copying  requests  that  were  accomplished  by  the  contractor  were 
entered  into  a  log  book,  reflecting  the  date  of  the  request  and  an  expected 
return  date.  This  log  was  reviewed  daily  to  insure  timely  submission  of 
the  required  copies.  Turn  around  time  for  a  normal  size  document  was  one 

calendar  day.  During  the  period  of  the  contract  139,321  copies  of  pages  were 
provided. 


The  contractor  shall  provide  the  services  and  materials  indicated 


below  to  organize,  direct,  coordinate  and  control  the  tasks  set  forth  in 
the  Statement  of  Work. 

4.8.1  Contract  Work  Breakdown  Structure  (CWBS) 

The  contractor  shall  maintain  the  CWBS  and  dictionary  in  compli¬ 
ance  with  the  concepts  set  forth  in  MIL-STD-881.  The  negotiated  CWBS  shall 
provide  the  basis  for  further  evolutionary  extension  by  the  contractor  to 
lower  levels  during  the  performance  of  the  contract.  The  contractor  shall 
use  the  CWBS  as  the  primary  framework  for  contract  planning,  budgeting  and 
reporting  status  of  costs  and  schedule  to  the  Air  Force.  The  CWBS  shall 
be  maintained  and  updated  by  the  contractor  during  the  execution  of  the 
contract  according  to  the  CDRL.  During  the  performance  of  the  contract, 
the  contractor  shall  update  the  CWBS  as  additional  system  definition  is 
accomplished  and  may  propose  alternatives  for  improvement.  Authority  for 
approval  and  use  of  such  alternatives  rests  with  the  DAIS  Program  Manager 
through  the  PCO. 

4. 8.1.1  Contract  Work  Breakdown  Structure  (CWBS)  Delivery 

The  Contract  Work  Breakdown  Structure,  Table  IV,  was  designed 
to  give  maximum  visibility  for  cost  control  to  provide  easy  correlation  to 
the  tasks  outlined  in  the  work  statement  and  division  of  tasks  within  the 
project  organization.  By  using  the  WBS  the  total  program  was  divided  into 
many  small  "work  packages1*  which  were  individually  budgeted.  This  detailed 
cost  break  out  concept  was  used  to  control  costs  throughout  the  term  of  the 
contract.  The  costs  of  the  individual  work  tasks  in  the  WBS  were  continually 
monitored  and  the  manager  was  alerted  to  any  deviations  from  budget  which 
permitted  appropriate  and  timely  corrective  action. 


Table  IV .  Contract  Work  Breakdown  Structure 


1  WORK  PACKAGE 

# 

DESCRIPTION 

LEVEL  1 

LEVEL  2 

LEVEL  3 

1 

DAIS  Documentation 

1.1 

Library  Maintenance 

1.1.1 

Printing  of  DAIS  Documents 

1.1.2 

Distribution  of  DAIS  Documents 

1.1.3 

Inventory  Maintenance 

1.1.4 

Master  File  Maintenance 

1.2 

Preparation  of  Bus  Monitor  Specification 

1.3 

Drafting  Support 

1.4 

Editing 

1.4.1 

Technical  Editing/Revrite 

1.1*. 2 

Format  Editing/Proofreading 

1.5 

Audits 

1.5.1 

Physical  Audit  of  Universal  Remote  Terminal  (URT) 

1.5.2 

Physical  Audit  of  Modular  Programmable  Display 
Generator  (MFDG) 

1.5.3 

Physical  Audit  of  Bus  Monitor  Unit  (BMU) 

1.5.4 

Software  Audit  of  Simulated  Subsystem  Data 

Formmater  (SSDF)  Program 

1.6 

DAIS  Control  Board  Support 

1.7 

Copying  Support 

1.8 

Program  Management 

1.8.1 

Contract  Work  Breakdown  Structure  (CWBS) 

1.8.2 

Technical  Reporting 

1 _ j 

1.9 

1.8.3 

Schedule  and  Cost  Reporting 

DAIS  Information  Booklet 
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*+•8.2  Technical  Reporting 

The  contractor  shall  prepare  and  provide  to  the  government  a 
monthly  accounting  of  work  accomplished,  identification  of  problem  areas 
with  recommended  solutions  and  work  to  be  accomplished  during  the  next 
period.  This  information  shall  be  submitted  in  conformance  with  the  appro¬ 
priate  data  items  specified  in  the  CTRL. 

U.8.2.1  Technical  Reports  Submitted 

During  the  life  of  the  contract,  22  Monthly  R&D  Status  Reports 
were  submitted  which  covered  the  activities  of  the  contractor  during  the 
previous  month. 

*+.8.3  Schedule  and  Cost  Reporting 

The  contractor  shall  prepare  and  provide  to  the  government  a 
monthly  Program  Schedule  and  financial  reports  in  accordance  with  the 
appropriate  data  items  specified  in  the  CTRL. 

*+.8.3.1  Schedule  and  Cost  Reports  Submitted 

During  the  life  of  the  contract,  22  Monthly  Performance  and 
Cost  Reports  were  submitted  which  gave  a  break  out  by  tasks,  the  number  of 
dollars  and  hours  expended  during  the  previous  month,  and  the  cumulative 
totals  to  date. 

*+•9  DAIS  Information  Booklet 

Preparation  and  Reproduction  of  a  DAIS  Information  Booklet(Task  9). 
The  contractor  shall  develop  an  Information  Booklet  for  DAIS  by  utilizing 
existing  information  and/or  writing  new  material.  The  pictures,  illustration, 
etc.,  can  be  created  new  or  from  existing  items.  The  manual  is  to  be  15  to  20 
pages  and  U,000  copies  are  to  be  reproduced. 
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4.9.1 


DAIS  Information  Booklet  Contents 


A  twenty  page  multi-colored  Information  Booklet  was  developed. 

This  booklet  covered  in  the  introduction  the  efforts  that  have  gone  into 
Avionic  Systems  Integration  and  then  discussed  in  detail  the  Controls  and 
Displays,  Multiplex  Data  Bus,  Processors,  Avionics  Software,  Test  Support 
Facility,  and  Avionics  Costs.  The  last  section  of  the  booklet  outlines  what 
lies  ahead  in  the  avionic  systems  information  fusion  concepts  and  technologies 
being  advanced  by  the  Avionics  Laboratory. 

4.9.2  information  Booklet  Delivery 

Four  thousand  copies  of  the  booklet  were  delivered.  Initial  dist¬ 
ribution  of  approximately  two  thousand  booklets  were  made  to  Major  Air 
Force  Commands,  Numbered  Air  Forces  and  active  flying  units. 
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5. 


CONCLUSIONS  AND  RECOMMENDATIONS 


The  DAIS  program,  which  did  not  include  the  full  implementation 
of  configuration  management  from  its  inception  in  1973*  presented  a  unique 
set  of  situations  which  had  to  be  considered  in  the  organization  and 
implementation  of  a  configuration  management  effort  in  1975. 

Considerations  included: 

•  DAIS  Concepts  and  ultimate  goals 

•  Status  of  the  DAIS  Program  with  respect  to 
hardware,  software  and  program  data  availability 

at  the  time  of  configuration  management  implementation 

•Organic  capabilities  available  to  implement  a  program 
of  configuration  management 

•  Impact  on  contractor  working  on  contract  for  the  design 
and  development  of  items  required  as  an  integral  part 
of  the  DAIS  Program 

By  necessity  this  effort  was  formulated  in  a  pattern  which  imposed  the 
basic  policies  and  procedures  of  configuration  management  in  a  form  most 
compatible  with  criteria  imposed  by  an  "in  process"  program. 

To  obtain  control  of  the  DAIS  configuration  items  of  hardware  and 
software,  two  major  phases  were  necessary.  The  first  involved  documentation 
and  the  second  related  to  the  hardware  and  software  and  their  relationship 
to  the  documentation. 

5.1  Phase  I  -  Documentation  Control 

Documentation  control  was  highly  successful  in  the  effort  of 
gathering,  reviewing,  cataloging  and  filing  of  all  DAIS  specifications, 
interface  control  documents,  user’s  manuals,  engineering  drawings  and  test 
plans  and  procedures.  A  total  of  185  documents  were  reviewed,  approved, 
printed  and  distributed  to  in-house  Air  Force  units ,  other  government  agencies , 
and  civilian  industry. 
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5.2 


Phase  II  -  Product  Control 


Product  control  was  also  successful  hut  not  to  the  same  degree 
as  Phase  I.  Configuration  control  was  attained  over  the  software  that  had 
been  developed  by  insuring  that  it  had  been  developed  as  required  by  the 
specifications  and  was  compatible  to  its  associated  listing.  Selected  items 
of  hardware  used  in  the  development  .of  the  DAIS  program  underwent  a  physical 
audit  which  revealed  many  discrepancies  between  the  physical  units  and  the 
documents  describing  them.  These  were  corrected  and  a  higher  degree  of  control 
over  changes  to  the  hardware  was  initiated,  but  this  came  about  too  late  in  the 
program  to  make  a  significant  contribution  to  control  of  the  hardware.  This 
was  evidenced  by  the  fact  that  only  three  hardware-related  ECPs  were  processed. 
It  would  be  difficult  to  assess  how  the  overall  hardware  met  the  criteria  estab¬ 
lished  by  its  associated  documentation  due  to  the  limited  scope  of  the  hardware 
physical  audits. 

Therefore  it  is  recommended  that  in  future  programs  that  the  prin¬ 
ciples  of  Configuration  Management  be  implemented  as  early  as  possible  in  the 
program  life  cycle.  This  should  be  accomplished  by  the  establishment  of  a 
Configuration  Management  Office  (CMO)  in  the  Program  Office  (PO).  In  the  early 
phases  the  CMO  should  provide  control  of  performance /system  specifications 
and  provide  visibility  into  the  development  process.  At  the  same  time  the 
PO  should  establish  contractural  requirements  for  CM  on  the  contractors  who 
are  involved  in  the  development  of  software,  hardware  or  facility  support. 

Also  the  CMO  should  act  as  the  focal  point  within  the  PO  for  centralized 

specification  control  and  for  hardware  configuration  status ,  including 
identification  and  control.  CM  snould  be  applied  to  all  elements  of  the 

program— hardware,  computer  programs ,  support  equipment,  facilities  and 
documentation  (specifications,  plans,  drawings,  manuals,  etc).  The  basic 
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approach  is  to  use  the  standard  CM  techniques  but  retain  flexibility  to 
tailor  requirements  for  each  particular  program. 
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